home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / security / doc / clippings / 02-FAQ.1.6 < prev    next >
Encoding:
Text File  |  1993-07-15  |  49.9 KB  |  1,236 lines

  1. Archive-name: alt-security-faq
  2. Last-modified: 1993/6/30
  3. Version: 1.6
  4.  
  5. Version History:
  6.  
  7. 1.6    Minor revisions, meant to bring it a bit more up to date.
  8. 1.5    Structural revision.
  9. 1.4    Fixed John Haugh's name, modified entry for "shadow"
  10.     Added Ulf Kieber's update on the rainbow series
  11.     Added bit about Karila paper
  12. 1.3:    Tweak for comp.security.misc/news.answers
  13.     Updated entry for orange book (foreign purchases)
  14. 1.2:    Undocumented prior to this
  15.  
  16. ---------------------------------------------------------------------------
  17.     Almost Everything You Ever Wanted To Know About Security*
  18.                *(but were afraid to ask!)
  19.  
  20. This document is meant to answer some of the questions which regularly
  21. appear in the Usenet newsgroups "comp.security.misc" and "alt.security",
  22. and is meant to provide some background to the subject for newcomers to
  23. that newsgroup.
  24.  
  25. This FAQ is maintained by Alec Muffett (Alec.Muffett@uk.sun.com), with
  26. contributions from numerous others; the views expressed in the document
  27. are the personal views of the author(s), and it should not be inferred
  28. that they are necessarily shared by anyone with whom the author(s) are
  29. now, or ever may be, associated.
  30.  
  31. Many thanks go to (in no particular order): Steve Bellovin, Matt Bishop,
  32. Mark Brader, Ed DeHart, Dave Hayes, Jeffrey Hutzelman, William LeFebvre,
  33. Wes Morgan, Rob Quinn, Chip Rosenthal, Wietse Venema, Gene Spafford,
  34. John Wack and Randall Atkinson.
  35.  
  36. Disclaimer: Every attempt is made to ensure that the information
  37. contained in this FAQ is up to date and accurate, but no responsibility
  38. will be accepted for actions resulting from information gained herein.
  39.  
  40. Questions which this document addresses:
  41.  
  42.  
  43. Q.1 What are alt.security and comp.security.misc for?
  44. Q.2 Whats the difference between a hacker and a cracker?
  45. Q.3 What is "security through obscurity"
  46. Q.4 What makes a system insecure?
  47. Q.5 What tools are there to aid security?
  48. Q.6 Isn't it dangerous to give cracking tools to everyone?
  49. Q.7 Where can I get these tools?
  50. Q.8 Why and how do systems get broken into?
  51. Q.9 Who can I contact if I get broken into?
  52. Q.10 What is a firewall?
  53. Q.11 Why shouldn't I use setuid shell scripts?
  54. Q.12 Why shouldn't I leave "root" permanently logged on the console?
  55. Q.13 Why shouldn't I create Unix accounts with null passwords?
  56. Q.14 What security holes are associated with X-windows (and other WMs)?
  57. Q.15 What security holes are associated with NFS?
  58. Q.16 How can I generate safe passwords?
  59. Q.17 Why are passwords so important?
  60. Q.18 How many possible passwords are there?
  61. Q.19 Where can I get more information?
  62. Q.20 How silly can people get?
  63.  
  64. ---------------------------------------------------------------------------
  65.  
  66.  
  67. Q.1 What are alt.security and comp.security.misc for?
  68.  
  69. Comp.security.misc is a forum for the discussion of computer security,
  70. especially those relating to Unix (and Unix like) operating systems.
  71. Alt.security used to be the main newsgroup covering this topic, as well
  72. as other issues such as car locks and alarm systems, but with the
  73. creation of comp.security.misc, this may change.
  74.  
  75. This FAQ will concentrate wholly upon computer related security issues.
  76.  
  77. The discussions posted range from the likes of "What's such-and-such
  78. system like?" and "What is the best software I can use to do so-and-so"
  79. to "How shall we fix this particular bug?", although there is often a
  80. low signal to noise ratio in the newsgroup (a problem which this FAQ
  81. hopes to address).
  82.  
  83. The most common flamewars start when an apparent security novice posts a
  84. message saying "Can someone explain how the such-and-such security hole
  85. works?" and s/he is immediately leapt upon by a group of self appointed
  86. people who crucify the person for asking such an "unsound" question in a
  87. public place, and flame him/her for "obviously" being a cr/hacker.
  88.  
  89. Please remember that grilling someone over a high flame on the grounds
  90. that they are "a possible cr/hacker" does nothing more than generate a
  91. lot of bad feeling.  If computer security issues are to be dealt with in
  92. an effective manner, the campaigns must be brought (to a large extent)
  93. into the open.
  94.  
  95. Implementing computer security can turn ordinary people into rampaging
  96. paranoiacs, unable to act reasonably when faced with a new situation.
  97. Such people take an adversarial attitude to the rest of the human race,
  98. and if someone like this is in charge of a system, users will rapidly
  99. find their machine becoming more restrictive and less friendly (fun?) to
  100. use.
  101.  
  102. This can lead to embarrasing situations, eg: (in one university) banning
  103. a head of department from the college mainframe for using a network
  104. utility that he wasn't expected to.  This apparently required a lot of
  105. explaining to an unsympathetic committee to get sorted out.
  106.  
  107. A more sensible approach is to secure a system according to its needs,
  108. and if its needs are great enough, isolate it completely.  Please, don't
  109. lose your sanity to the cause of computer security; it's not worth it.
  110.  
  111.  
  112. Q.2 What's the difference between a hacker and a cracker?
  113.  
  114. Lets get this question out of the way right now:
  115.  
  116. On USENET, calling someone a "cracker" is an unambiguous statement that
  117. some person persistently gets his/her kicks from breaking from into
  118. other peoples computer systems, for a variety of reasons.  S/He may pose
  119. some weak justification for doing this, usually along the lines of
  120. "because it's possible", but most probably does it for the "buzz" of
  121. doing something which is illicit/illegal, and to gain status amongst a
  122. peer group.
  123.  
  124. Particularly antisocial crackers have a vandalistic streak, and delete
  125. filestores, crash machines, and trash running processes in pursuit of
  126. their "kicks".
  127.  
  128. The term is also widely used to describe a person who breaks copy
  129. protection software in microcomputer applications software in order to
  130. keep or distribute free copies.
  131.  
  132. On USENET, calling someone a "hacker" is usually a statement that said
  133. person holds a great deal of knowledge and expertise in the field of
  134. computing, and is someone who is capable of exercising this expertise
  135. with great finesse.  For a more detailed definition, readers are
  136. referred to the Jargon File [Raymond].
  137.  
  138. In the "real world", various media people have taken the word "hacker"
  139. and coerced it into meaning the same as "cracker" - this usage
  140. occasionally appears on USENET, with disastrous and confusing results.
  141.  
  142. Posters to the security newsgroups should note that they currently risk
  143. a great deal of flamage if they use the word "hacker" in place of
  144. "cracker" in their articles.
  145.  
  146. NB: nowhere in the above do I say that crackers cannot be true hackers.
  147. It's just that I don't say that they are...
  148.  
  149.  
  150. Q.3 What is "security through obscurity"
  151.  
  152. Security Through Obscurity (STO) is the belief that any system can be
  153. secure so long as nobody outside of its implementation group is allowed
  154. to find out anything about its internal mechanisms.  Hiding account
  155. passwords in binary files or scripts with the presumption that "nobody
  156. will ever find it" is a prime case of STO.
  157.  
  158. STO is a philosophy favoured by many bureaucratic agencies (military,
  159. governmental, and industrial), and it used to be a major method of
  160. providing "pseudosecurity" in computing systems.
  161.  
  162. Its usefulness has declined in the computing world with the rise of open
  163. systems, networking, greater understanding of programming techniques, as
  164. well as the increase in computing power available to the average person.
  165.  
  166. The basis of STO has always been to run your system on a "need to know"
  167. basis.  If a person doesn't know how to do something which could impact
  168. system security, then s/he isn't dangerous.
  169.  
  170. Admittedly, this is sound in theory, but it can tie you into trusting a
  171. small group of people for as long as they live.  If your employees get
  172. an offer of better pay from somewhere else, the knowledge goes with
  173. them, whether the knowledge is replaceable or not.  Once the secret gets
  174. out, that is the end of your security.
  175.  
  176. Nowadays there is also a greater need for the ordinary user to know
  177. details of how your system works than ever before, and STO falls down a
  178. as a result.  Many users today have advanced knowledge of how their
  179. operating system works, and because of their experience will be able to
  180. guess at the bits of knowledge that they didn't "need to know".  This
  181. bypasses the whole basis of STO, and makes your security useless.
  182.  
  183. Hence there is now a need is to to create systems which attempt to be
  184. algorithmically secure (Kerberos, Secure RPC), rather than just
  185. philosophically secure.  So long as your starting criteria can be met,
  186. your system is LOGICALLY secure.
  187.  
  188. Incidentally, "Shadow Passwords" (below) are sometimes dismissed as STO,
  189. but this is incorrect, since (strictly) STO depends on restricting
  190. access to an algorithm or technique, whereas shadow passwords provide
  191. security by restricting access to vital data.
  192.  
  193.  
  194. Q.4 What makes a system insecure?
  195.  
  196. Switching it on.  The adage usually quoted runs along these lines:
  197.  
  198.  "The only system which is truly secure is one which is switched off
  199.  and unplugged, locked in a titanium lined safe, buried in a concrete
  200.  bunker, and is surrounded by nerve gas and very highly paid armed
  201.  guards.  Even then, I wouldn't stake my life on it."
  202.  
  203. (the original version of this is attributed to Gene Spafford)
  204.  
  205. A system is only as secure as the people who can get at it.  It can be
  206. "totally" secure without any protection at all, so long as its continued
  207. good operation is important to everyone who can get at it, assuming all
  208. those people are responsible, and regular backups are made in case of
  209. hardware problems.  Many laboratory PC's quite merrily tick away the
  210. hours like this.
  211.  
  212. The problems arise when a need (such as confidentiality) has to be
  213. fulfilled.  Once you start putting the locks on a system, it is fairly
  214. likely that you will never stop.
  215.  
  216. Security holes manifest themselves in (broadly) four ways:
  217.  
  218. 1) Physical Security Holes.
  219.  
  220. - Where the potential problem is caused by giving unauthorised persons
  221. physical access to the machine, where this might allow them to perform
  222. things that they shouldn't be able to do.
  223.  
  224. A good example of this would be a public workstation room where it would
  225. be trivial for a user to reboot a machine into single-user mode and muck
  226. around with the workstation filestore, if precautions are not taken.
  227.  
  228. Another example of this is the need to restrict access to confidential
  229. backup tapes, which may (otherwise) be read by any user with access to
  230. the tapes and a tape drive, whether they are meant to have permission or
  231. not.
  232.  
  233. 2) Software Security Holes
  234.  
  235. - Where the problem is caused by badly written items of "privledged"
  236. software (daemons, cronjobs) which can be compromised into doing things
  237. which they shouldn't oughta.
  238.  
  239. The most famous example of this is the "sendmail debug" hole (see
  240. bibliography) which would enable a cracker to bootstrap a "root" shell.
  241. This could be used to delete your filestore, create a new account, copy
  242. your password file, anything.
  243.  
  244. (Contrary to popular opinion, crack attacks via sendmail were not just
  245. restricted to the infamous "Internet Worm" - any cracker could do this
  246. by using "telnet" to port 25 on the target machine.  The story behind a
  247. similar hole (this time in the EMACS "move-mail" software) is described
  248. in [Stoll].)
  249.  
  250. New holes like this appear all the time, and your best hopes are to:
  251.  
  252.   a: try to structure your system so that as little software as possible
  253.   runs with root/daemon/bin privileges, and that which does is known to
  254.   be robust.
  255.  
  256.   b: subscribe to a mailing list which can get details of problems
  257.   and/or fixes out to you as quickly as possible, and then ACT when you
  258.   receive information.
  259.  
  260. 3) Incompatible Usage Security Holes
  261.  
  262. - Where, through lack of experience, or no fault of his/her own, the
  263. System Manager assembles a combination of hardware and software which
  264. when used as a system is seriously flawed from a security point of view.
  265. It is the incompatibility of trying to do two unconnected but useful
  266. things which creates the security hole.
  267.  
  268. Problems like this are a pain to find once a system is set up and
  269. running, so it is better to build your system with them in mind.  It's
  270. never too late to have a rethink, though.
  271.  
  272. Some examples are detailed below; let's not go into them here, it would
  273. only spoil the surprise.
  274.  
  275. 4) Choosing a suitable security philosophy and maintaining it.
  276.  
  277. >From: Gene Spafford <spaf@cs.purdue.edu>
  278. >The fourth kind of security problem is one of perception and
  279. >understanding.  Perfect software, protected hardware, and compatible
  280. >components don't work unless you have selected an appropriate security
  281. >policy and turned on the parts of your system that enforce it.  Having
  282. >the best password mechanism in the world is worthless if your users
  283. >think that their login name backwards is a good password! Security is
  284. >relative to a policy (or set of policies) and the operation of a system
  285. >in conformance with that policy.
  286.  
  287.  
  288. Q.5 What tools are there to aid security?
  289.  
  290. 1) "COPS"
  291.  
  292. Managed by Dan Farmer, this is a long established suite of shell scripts
  293. which forms an extensive security testing system; There is a rudimentary
  294. password cracker, and routines to check the filestore for suspicious
  295. changes in setuid programs, others to check permissions of essential
  296. system and user files, and still more to see whether any system software
  297. behaves in a way which could cause problems.
  298.  
  299. The software comes in two versions - one written in Perl and one
  300. (largely equivalent) written in shell scripts.  The latest version is
  301. very up-to-date on Unix Security holes.
  302.  
  303. 2) "Crack" (+ "UFC").
  304.  
  305. Written by Alec Muffett, this is a program written with one purpose in
  306. mind: to break insecure passwords.  It is probably the most efficent and
  307. friendly password cracker that is publically available, with the ability
  308. to let the user to specify precisely how to form the words to use as
  309. guesses at users passwords.
  310.  
  311. It also has an inbuilt networking capability, allowing the load of
  312. cracking to be spread over as many machines as are available on a
  313. network, and it is supplied with an optimised version of the Unix crypt()
  314. algorithm.
  315.  
  316. An even faster version of the crypt() algorithm, "UFC" by Michael Glad,
  317. is freely available on the network, and the latest versions of UFC and
  318. Crack are compatible and can be easily hooked together.
  319.  
  320. 3) NPasswd (Clyde Hoover) & Passwd+ (Matt Bishop)
  321.  
  322. These programs are written to redress the balance in the password
  323. cracking war.  They provide replacements for the standard "passwd"
  324. command, but prevent a user from selecting passwords which are easily
  325. compromised by programs like Crack.
  326.  
  327. Several versions of these programs are available on the network, hacked
  328. about to varying degrees in order to provide compatibility for System V
  329. based systems, NIS/YP, shadow password schemes, etc.  The usual term for
  330. this type of program is a 'fascist' password program.
  331.  
  332. 4) "Shadow" - a Shadow Password Suite
  333.  
  334. This program suite (by John F Haugh II) is a set of program and function
  335. replacements (compatible with most Unixes) which implements shadow
  336. passwords, ie: a system where the plaintext of the password file is
  337. hidden from all users except root, hopefully stopping all password
  338. cracking attempts at source.  In combination with a fascist passwd
  339. frontend, it should provide a good degree of password file robustness.
  340.  
  341. >From: jfh@rpp386.lonestar.org (John F. Haugh II)
  342. >Shadow does much more than hide passwords.  It also provides for
  343. >terminal access control, user and group administration, and a few
  344. >other things which I've forgotten.  There are a dozen or more
  345. >commands in the suite, plus a whole slew of library functions.
  346.  
  347. 5) TCP Wrappers (Wietse Venema)
  348.  
  349. These are programs which provide a front-end filter to many of the
  350. network services which Unix provides by default.  If installed, they can
  351. curb otherwise unrestricted access to potential dangers like incoming
  352. FTP/TFTP, Telnet, etc, and can provide extra logging information, which
  353. may be of use if it appears that someone is trying to break in.
  354.  
  355. 6) SecureLib
  356.  
  357. >From: phil@pex.eecs.nwu.edu (William LeFebvre)
  358. >You may want to add a mention of securelib, a security enhancer
  359. >available for SunOS version 4.1 and higher.
  360.  
  361. >Securelib contains replacement routines for three kernel calls:
  362. >accept(), recvfrom(), recvmsg().  These replacements are compatible with
  363. >the originals, with the additional functionality that they check the
  364. >Internet address of the machine initiating the connection to make sure
  365. >that it is "allowed" to connect.  A configuration file defines what
  366. >hosts are allowed for a given program.  Once these replacement routines
  367. >are compiled, they can be used when building a new shared libc library.
  368. >The resulting libc.so can then be put in a special place.  Any program
  369. >that should be protected can then be started with an alternate
  370. >LD_LIBRARY_PATH.
  371.  
  372. 7) SPI
  373.  
  374. >From: Gene Spafford <spaf@cs.purdue.edu>
  375. >Sites connected with the Department of Energy and some military
  376. >organizations may also have access to the SPI package.  Interested (and
  377. >qualified) users should contact the CIAC at LLNL for details.
  378.  
  379. >SPI is a screen-based administrator's tool that checks configuration
  380. >options, includes a file-change (integrity) checker to monitor for
  381. >backdoors and viruses, and various other security checks.  Future
  382. >versions will probably integrate COPS into the package.  It is not
  383. >available to the general public, but it is available to US Dept of
  384. >Energy contractors and sites and to some US military sites.  A version
  385. >does or will exist for VMS, too.  Further information on availabilty can
  386. >be had from the folks at the DoE CIAC.
  387.  
  388. 8) CrackLib
  389.  
  390. Cracklib is a C library containing a routine which may be wired into all
  391. sorts of "passwd"-like programs; not just Unix, but with a little effor
  392. it could probably go onto VMS (this is being worked upon), or many other
  393. systems.
  394.  
  395. Using "CrackLib" allows you to wire proactive password checking into
  396. _any_ of you applications; it is an offshoot of the the version 5
  397. "Crack" software, and contains a considerable number of ideas nicked
  398. >From the new software.
  399.  
  400.  
  401. Q.6 Isn't it dangerous to give cracking tools to everyone?
  402.  
  403. That depends on your point of view.  Some people have complained that
  404. giving unrestricted public access to programs like COPS and Crack is
  405. irresponsible because the "baddies" can get at them easily.
  406.  
  407. Alternatively, you may believe that the really bad "baddies" have had
  408. programs like this for years, and that it's really a stupendously good
  409. idea to give these programs to the good guys too, so that they may check
  410. the integrity of their system before the baddies get to them.
  411.  
  412. So, who wins more from having these programs freely available? The good
  413. guys or the bad ? You decide, but remember that less honest tools than
  414. COPS and Crack tools were already out there, and most of the good guys
  415. didn't have anything to help.
  416.  
  417.  
  418. Q.7 Where can I get these tools?
  419.  
  420. COPS:
  421.  
  422.   V1.04, available for FTP from cert.sei.cmu.edu in pub/cops and
  423.   archive.cis.ohio-state.edu in pub/cops.
  424.  
  425. Crack/UFC:
  426.  
  427.   Crack v4.1f and UFC Patchlevel 1.  Get both of them.
  428.  
  429.   Available from:         ftp.uu.net (137.39.1.9)
  430.   In the directory:       /usenet/comp.sources.misc/volume28
  431.   As:                     crack/part01.Z to part05.Z      ( 5 files )
  432.   And                     ufc-crypt/part01.Z & part02.Z   ( 2 files )
  433.  
  434. >From: glad@daimi.aau.dk (Michael Glad)
  435. >
  436. >A UNIX password cracker for the Thinking Machine CM/2 and CM/200
  437. >Connection Machines is available for FTP from
  438. >
  439. >    ftp.denet.dk:/pub/misc/cm200-UFC.tar.Z
  440. >
  441. >To quote the README file:
  442. >
  443. > Overview
  444. >
  445. > This is a password cracker for the Thinking Machines CM/2 and CM/200
  446. > Connection Machines. It features
  447. >
  448. >     o A standalone dictionary preprocessor accepting a
  449. >      language of rewrite rules compatible with the one
  450. >      found in Alec Muffets 'Crack' password cracker as of
  451. >         release 4.1f.
  452. >
  453. >    o An optimized port of the UFC-crypt: a fast implementation
  454. >      of the UNIX crypt(3) function developed by Michael Glad and
  455. >      donated to the Free Software Foundation (FSF).
  456. >
  457. >    o The password cracker itself. It supports restart of crashed
  458. >      runs and incremental use. Incremental use means that when
  459. >      you use a fixed dictionary, the cracker can maintain a status
  460. >      file of already cracked passwords and passwords considered
  461. >      uncrackable (because they've been tested in previous runs).
  462. >      Thus it only has to waste CPU cycles on new accounts and accounts
  463. >      with changed passwords.
  464. >
  465. >    o When run with a _large_ dictionary (a 1 million word dictionary
  466. >      obtained by preprocessing /usr/dict/words), the cracker can
  467. >      test in excess of 50,000 passwords a second on a CM/200 with
  468. >      8192 processors.
  469. > [...]
  470.  
  471. NPasswd:
  472.  
  473.   Currently suffering from being hacked about by many different people.
  474.   Version 2.0 is in the offing, but many versions exist in many
  475.   different configurations. Will chase this up with authors - AEM
  476.  
  477. Passwd+:
  478.  
  479.   "alpha version, update 3" - beta version due soon.  Available from
  480.   dartmouth.edu as pub/passwd+.tar.Z
  481.  
  482. Shadow:
  483.  
  484.   This is available from the comp.sources.misc directory at any major
  485.   USENET archive - relevant files are in:
  486.  
  487.         usenet/comp.sources.misc/volume26
  488.         usenet/comp.sources.misc/volume28
  489.         usenet/comp.sources.misc/volume29
  490.         usenet/comp.sources.misc/volume30
  491.         usenet/comp.sources.misc/volume32
  492.  
  493. - the contents of which are needed, for a full set of patches.
  494.  
  495. TCP Wrappers:
  496.  
  497.   Available for anonymous FTP:
  498.  
  499.     ftp.win.tue.nl: pub/security/log_tcp.shar.Z
  500.     cert.sei.cmu.edu: pub/network_tools/tcp_wrapper.shar
  501.  
  502. Securelib:
  503.  
  504.   The latest version of securelib is available via anonymous FTP from the
  505.   host "eecs.nwu.edu".  It is stored in the file "pub/securelib.tar".
  506.  
  507. CrackLib:
  508.  
  509.   Posted to "comp.sources.misc", and therefore available from any major
  510.   usenet archive. A reference copy (+ large dictionary) can be FTP'ed from:
  511.  
  512.      black.ox.ac.uk:~ftp/src/security/cracklib25.tar.Z
  513.  
  514.   - if you search for CrackLib on "Archie", care should be taken to
  515.   get the package from a comp.sources.misc archive; beware confusing
  516.   it with a package of the same name, which was hacked into "npasswd".
  517.  
  518.  
  519. Q.8 Why and how do systems get broken into?
  520.  
  521. This is hard to answer definitively.  Many systems which crackers break
  522. into are only used as a means of entry into yet more systems; by hopping
  523. between many machines before breaking into a new one, the cracker hopes
  524. to confuse any possible pursuers and put them off the scent.  There is
  525. an advantage to be gained in breaking into as many different sites as
  526. possible, in order to "launder" your connections.
  527.  
  528. Another reason may be psychological: some people love to play with
  529. computers and stretch them to the limits of their capabilities.
  530.  
  531. Some crackers might think that it's "really neat" to hop over 6 Internet
  532. machines, 2 gateways and an X.25 network just to knock on the doors of
  533. some really famous company or institution (eg: NASA, CERN, AT+T, UCB).
  534. Think of it as inter-network sightseeing.
  535.  
  536. This view is certainly appealing to some crackers, and certainly leads
  537. to both the addiction and self-perpetuation of cracking.
  538.  
  539. As to the "How" of the question, this is again a very sketchy area.  In
  540. universities, it is extremely common for computer account to be passed
  541. back and forth between undergraduates:
  542.  
  543.   "Mary gives her account password to her boyfriend Bert at another
  544.   site, who has a friend Joe who "plays around on the networks".  Joe
  545.   finds other crackable accounts at Marys site, and passes them around
  546.   amongst his friends..." pretty soon, a whole society of crackers is
  547.   playing around on the machines that Mary uses.
  548.  
  549. This sort of thing happens all the time, and not just in universities.
  550. One solution is in education.  Do not let your users develop attitudes
  551. like this one:
  552.  
  553.        "It doesn't matter what password I use on _MY_ account,
  554.             after all, I only use it for laserprinting..."
  555.                 - an Aberystwyth Law student, 1991
  556.  
  557. Teach them that use of the computer is a group responsibility.  Make
  558. sure that they understand that a chain is only as strong as it's weak
  559. link.
  560.  
  561. Finally, when you're certain that they understand your problems as a
  562. systems manager and that they totally sympathise with you, configure
  563. your system in such a way that they can't possibly get it wrong.
  564.  
  565. Believe in user education, but don't trust to it alone.
  566.  
  567.  
  568. Q.9 Who can I contact if I get broken into?
  569.  
  570. If you're connected to the Internet, you should certainly get in touch
  571. with CERT, the Computer Emergency Response Team.
  572.  
  573.     To quote the official blurb:
  574.  
  575. >From: Ed DeHart
  576. > The Computer Emergency Response Team (CERT) was formed by the Defense
  577. > Advanced Research Projects Agency (DARPA) in 1988 to serve as a focal
  578. > point for the computer security concerns of Internet users.  The
  579. > Coordination Center for the CERT is located at the Software Engineering
  580. > Institute, Carnegie Mellon University, Pittsburgh, PA.
  581.  
  582. > Internet E-mail: cert@cert.sei.cmu.edu
  583. > Telephone: 412-268-7090 24-hour hotline:
  584. >     CERT/CC personnel answer 7:30a.m. to 6:00p.m. EST(GMT-5)/EDT(GMT-4),
  585. >     and are on call for emergencies during other hours.
  586.  
  587. ...and also, the umbrella group "FIRST", which mediates between the
  588. incident handling teams themselves...
  589.  
  590. >From: John Wack <wack@csrc.ncsl.nist.gov>
  591. >[...] FIRST is actually a very viable and growing
  592. >organization, of which CERT is a member.  It's not actually true that,
  593. >if you're connected to the Internet, you should call CERT only - that
  594. >doesn't do justice to the many other response teams out there and in the
  595. >process of forming.
  596.  
  597. >NIST is currently the FIRST secretariat; we maintain an anonymous ftp
  598. >server with a directory of FIRST information (csrc.ncsl.nist.gov:
  599. >~/pub/first).  This directory contains a contact file that lists the
  600. >current members and their constituencies and contact information
  601. >(filename "first-contacts").
  602.  
  603. >While CERT is a great organization, other response teams who do handle
  604. >incidents on their parts of the Internet merit some mention as well -
  605. >perhaps mentioning the existence of this file would help to do that in a
  606. >limited space.
  607.  
  608. The file mentioned is a comprehensive listing of contact points per
  609. network for security incidents.  It is too large to reproduce here, I
  610. suggest that the reader obtains a copy for his/her self by the means
  611. given.
  612.  
  613.  
  614. Q.10 What is a firewall?
  615.  
  616. A (Internet) firewall is a machine which is attached (usually) between
  617. your site and a wide area network.  It provides controllable filtering
  618. of network traffic, allowing restricted access to certain internet port
  619. numbers (ie: services that your machine would otherwise provide to the
  620. network as a whole) and blocks access to pretty well everything else.
  621. Similar machines are available for other network types, too.
  622.  
  623. Firewalls are an effective "all-or-nothing" approach to dealing with
  624. external access security, and they are becoming very popular, with the
  625. rise in Internet connectivity.
  626.  
  627. For more information on these sort of topics, see the Gateway paper by
  628. [Cheswick], below.
  629.  
  630.  
  631. Q.11 Why shouldn't I use setuid shell scripts?
  632.  
  633. You shouldn't use them for a variety of reasons, mostly involving bugs
  634. in the Unix kernel.  Here are a few of the more well known problems,
  635. some of which are fixed on more recent operating systems.
  636.  
  637. 1) If the script begins "#!/bin/sh" and a link (symbolic or otherwise)
  638. can be made to it with the name "-i", a setuid shell can be immediately
  639. obtained because the script will be invoked: "#!/bin/sh -i", ie: an
  640. interactive shell.
  641.  
  642. 2) Many kernels suffer from a race condition which can allow you to
  643. exchange the shellscript for another executable of your choice between
  644. the times that the newly exec()ed process goes setuid, and when the
  645. command interpreter gets started up.  If you are persistent enough, in
  646. theory you could get the kernel to run any program you want.
  647.  
  648. 3) The IFS bug: the IFS shell variable contains a list of characters to
  649. be treated like whitespace by a shell when parsing command names.  By
  650. changing the IFS variable to contain the "/" character, the command
  651. "/bin/true" becomes "bin true".
  652.  
  653. All you need do is export the modified IFS variable, install a command
  654. called "bin" in your path, and run a setuid script which calls
  655. "/bin/true".  Then "bin" will be executed whilst setuid.
  656.  
  657. If you really must write scripts to be setuid, either
  658.  
  659.   a) Put a setuid wrapper in "C" around the script, being very careful
  660.   to reset IFS and PATH to something sensible before exec()ing the
  661.   script.  If your system has runtime linked libraries, consider the
  662.   values of the LD_LIBRARY_PATH also.
  663.  
  664.   b) Use a scripting language like Perl which has a safe setuid
  665.   facility, and is proactively rabid about security.
  666.  
  667. - but really, it's safest not to use setuid scripts at all.
  668.  
  669.  
  670. Q.12 Why shouldn't I leave "root" permanently logged on the console?
  671.  
  672. Using a 'smart' terminal as console and leaving "/dev/console" world
  673. writable whilst "root" is logged in is a potential hole.  The terminal
  674. may be vulnerable to remote control via escape sequences, and can be
  675. used to 'type' things into the root shell.  The terminal type can
  676. usually be obtained via the "ps" command.
  677.  
  678. Various solutions to this can be devised, usually by giving the console
  679. owner and group-write access only , and then using the setgid mechanism
  680. on any program which has need to output to the console (eg: "write").
  681.  
  682.  
  683. Q.13 Why shouldn't I create Unix accounts with null passwords?
  684.  
  685. Creating an unpassworded account to serve any purpose is potentially
  686. dangerous, not for any direct reason, but because it can give a cracker
  687. a toehold.
  688.  
  689. For example, on many systems you will find a unpassworded user "sync",
  690. which allows the sysman to sync the disks without being logged in.  This
  691. appears to be both safe and innocuous.
  692.  
  693. The problem with this arises if your system is one of the many which
  694. doesn't do checks on a user before authorising them for (say) FTP.  A
  695. cracker might be able to connect to your machine for one of a variety of
  696. FTP methods, pretending to be user "sync" with no password, and then
  697. copy your password file off for remote cracking.
  698.  
  699. Although there are mechanisms to prevent this sort of thing happening in
  700. most modern vesions of Unix, to be totally secure requires an in-depth
  701. knowledge of every package on your system, and how it deals with the
  702. verification of users.  If you can't be sure, it's probably better not
  703. to leave holes like this around.
  704.  
  705. Another hole that having null-password accounts opens up is the
  706. possibility (on systems with runtime linked libraries) of spoofing
  707. system software into running your programs as the "sync" user, by
  708. changing the LD_LIBRARY_PATH variable to a library of your own devising,
  709. and running "login -p" or "su" to turn into that user.
  710.  
  711.  
  712. Q.14 What security holes are associated with X-windows (and other WMs)?
  713.  
  714. Lots, some which affect use of X only, and some which impact the
  715. security of the entire host system.
  716.  
  717. I would prefer not to go into too much detail here, and would refer any
  718. reader reader looking for detailed information to the other FAQ's in
  719. relevant newsgroups.  (comp.windows.*)
  720.  
  721. One point I will make is that X is one of those packages which often
  722. generates "Incompatible Usage" security problems, for instance the
  723. ability for crackers to run xsessions on hosts under accounts with no
  724. password (eg: sync), if it is improperly set up.  Read the question
  725. about unpassworded accounts in this FAQ.
  726.  
  727.  
  728. Q.15 What security holes are associated with NFS?
  729.  
  730. Lots, mostly to do with who you export your disks to, and how.  The
  731. security of NFS relies heavily upon who is allowed to mount the files
  732. that a server exports, and whether they are exported read only or not.
  733.  
  734. The exact format for specifying which hosts can mount an exported
  735. directory varies between Unix implementations, but generally the
  736. information is contained within the file "/etc/exports".
  737.  
  738. This file contains a list of directories and for each one, it has a
  739. series of either specific "hosts" or "netgroups" which are allowed to
  740. NFS mount that directory.  This list is called the "access list".
  741.  
  742. The "hosts" are individual machines, whilst "netgroups" are combinations
  743. of hosts and usernames specified in "/etc/netgroup".  These are meant to
  744. provide a method of finetuning access.  Read the relevant manual page
  745. for more information about netgroups.
  746.  
  747. The exports file also contains information about whether the directory
  748. is to be exported as read-only, read-write, and whether super-user
  749. access is to be allowed from clients which mount that directory.
  750.  
  751. The important point to remember is that if the access list for a
  752. particular directory in /etc/exports contains:
  753.  
  754. 1) <nothing>
  755.  
  756. Your directory can be mounted by anyone, anywhere.
  757.  
  758. 2) <a specific hostname>
  759.  
  760. Your directory can be mounted by anyone permitted to run the mount
  761. command at hostname.  This might not be a trustworthy person; for
  762. instance, if the machine is a PC running NFS, it could be anyone.
  763.  
  764. 3) <a netgroup name>
  765.  
  766. If the netgroup:
  767.  
  768. a) is empty, anyone can mount your directory, from anywhere.
  769.  
  770. b) contains "(,,)", anyone can mount your directory, from anywhere.
  771.  
  772. c) contains the name of a netgroup which is empty or contains "(,,)",
  773.    anyone can mount your directory, from anywhere.
  774.  
  775. d) contains "(hostname,,)", anyone on the named host who is permissioned
  776.    to mount files can mount your directory.
  777.  
  778. e) contains "(,username,)", the named user can mount your directory,
  779.    from anywhere.
  780.  
  781. 4) <a word which is neither a hostname or a netgroup>
  782.  
  783. If you meant to export the directory to the host "athena" but actually
  784. type "ahtena", the word "ahtena" is taken as a netgroup name, is found
  785. to be an empty netgroup, and thus the directory can be mounted by
  786. anyone, anywhere.
  787.  
  788. So, if you aren't careful about what you put into /etc/exports and
  789. /etc/netgroup you could find that a user with a PC could
  790.  
  791.   a) mount your mainframe filestore as a network disk
  792.   b) edit your /etc/passwd or .rhosts or /etc/hosts.equiv ...
  793.   c) log into your mainframe as another user, possibly "root"
  794.  
  795. Disclaimer: The above information may not be true for all platforms
  796. which provide an NFS serving capability, but is true for all of the ones
  797. in my experience (AEM).  It should be noted that the SAFE way to create
  798. an "empty" netgroup entry is:
  799.  
  800.                ngname (-,-,-)
  801.  
  802. Which is a netgroup which matches no-one on no-host on no-NIS-domain.
  803.  
  804.  
  805. Q.16 How can I generate safe passwords?
  806.  
  807. You can't.  The key word here is GENERATE.  Once an algorithm for
  808. creating passwords is specified using upon some systematic method, it
  809. merely becomes a matter of analysing your algorithm in order to find
  810. every password on your system.
  811.  
  812. Unless the algorithm is very subtle, it will probably suffer from a very
  813. low period (ie: it will soon start to repeat itself) so that either:
  814.  
  815.   a) a cracker can try out every possible output of the password
  816.   generator on every user of the system, or
  817.  
  818.   b) the cracker can analyse the output of the password program,
  819.   determine the algorithm being used, and apply the algorithm to other
  820.   users to determine their passwords.
  821.  
  822. A beautiful example of this (where it was disastrously assumed that a
  823. random number generator could generate an infinite number of random
  824. passwords) is detailed in [Morris & Thompson].
  825.  
  826. The only way to get a reasonable amount of variety in your passwords
  827. (I'm afraid) is to make them up.  Work out some flexible method of your
  828. own which is NOT based upon:
  829.  
  830.   1) modifying any part of your name or name+initials
  831.   2) modifying a dictionary word
  832.   3) acronyms
  833.   4) any systematic, well-adhered-to algorithm whatsoever
  834.  
  835. For instance, NEVER use passwords like:
  836.  
  837. alec7         - it's based on the users name (& it's too short anyway)
  838. tteffum        - based on the users name again
  839. gillian        - girlfiends name (in a dictionary)
  840. naillig        - ditto, backwards
  841. PORSCHE911     - it's in a dictionary
  842. 12345678     - it's in a dictionary (& people can watch you type it easily)
  843. qwertyui     - ...ditto...
  844. abcxyz        - ...ditto...
  845. 0ooooooo    - ...ditto...
  846. Computer     - just because it's capitalised doesn't make it safe
  847. wombat6     - ditto for appending some random character
  848. 6wombat     - ditto for prepending some random character
  849. merde3        - even for french words...
  850. mr.spock     - it's in a sci-fi dictionary
  851. zeolite     - it's in a geological dictionary
  852. ze0lite     - corrupted version of a word in a geological dictionary
  853. ze0l1te     - ...ditto...
  854. Z30L1T3     - ...ditto...
  855.  
  856. I hope that these examples emphasise that ANY password derived from ANY
  857. dictionary word (or personal information), modified in ANY way,
  858. constitutes a potentially guessable password.
  859.  
  860. For more detailed information in the same vein, you should read the
  861. APPENDIX files which accompany Crack [Muffett].
  862.  
  863.  
  864. Q.17 Why are passwords so important?
  865.  
  866. Because they are the first line of defence against interactive attacks
  867. on your system.  It can be stated simply: if a cracker cannot interact
  868. with your system(s), and he has no access to read or write the
  869. information contained in the password file, then he has almost no
  870. avenues of attack left open to break your system.
  871.  
  872. This is also why, if a cracker can at least read your password file (and
  873. if you are on a vanilla modern Unix, you should assume this) it is so
  874. important that he is not able to break any of the passwords contained
  875. therein.  If he can, then it is also fair to assume that he can (a) log
  876. on to your system and can then (b) break into "root" via an operating
  877. system hole.
  878.  
  879.  
  880. Q.18 How many possible passwords are there?
  881.  
  882. Most people ask this at one time or another, worried that programs like
  883. Crack will eventually grow in power until they can do a completely
  884. exhaustive search of all possible passwords, to break into a specific
  885. users' account - usually root.
  886.  
  887. If (to simplify the maths) we make the assumptions that:
  888.  
  889.   1) Valid passwords are created from a set of 62 chars [A-Za-z0-9]
  890.   2) Valid passwords are to be between 5 and 8 chars long
  891.  
  892. Then the size of the set of all valid passwords is: (in base 62)
  893.  
  894.                    100000b62 +
  895.                   1000000b62 +
  896.                  10000000b62 +
  897.                 100000000b62 =
  898.                 ---------
  899.                 111100000b62
  900.  
  901.               ~= 222000000000000 (decimal)
  902.  
  903. A figure which is far too large to usefully undertake an exhaustive
  904. search with current technologies.  Don't forget, however, that passwords
  905. CAN be made up with even more characters then this; you can use <space>,
  906. all the punctuation characters, and symbols (~<>|\#$%^&*) too.  If you
  907. can use some of all the 95 non-control characters in passwords, this
  908. increases the search space for a cracker to cover even further.
  909.  
  910. However, it's still MUCH more efficient for a cracker to get a copy of
  911. "Crack", break into ANY account on the system (you only need one), log
  912. onto the machine, and spoof his way up to root priviledges via operating
  913. systems holes.
  914.  
  915. Take comfort from these figures.  If you can slam the door in the face
  916. of a potential crackers with a robust password file, you have sealed
  917. most of the major avenues of attack immediately.
  918.  
  919.  
  920. Q.19 Where can I get more information?
  921.  
  922. Books:
  923.  
  924. [Kochan & Wood]
  925. Unix System Security
  926.  
  927. A little dated for modern matters, but still a very good book on the
  928. basics of Unix security.
  929.  
  930. [Spafford & Garfinkel]
  931. Practical Unix Security
  932.  
  933. This wonderful book is a worthy successor to the above, and covers a
  934. wide variety of the topics which the Unix (and some non Unix) system
  935. manager of the 90's will come across.
  936.  
  937. >From: Gene Spafford <spaf@cs.purdue.edu>
  938. >Mention appendix E in "Practical Unix Security."
  939.  
  940. Okay: Appendix E contains an extensive bibliography with even more
  941. pointers to security books than this FAQ contains.
  942.  
  943. [Stoll]
  944. The Cuckoo's Egg
  945.  
  946. A real life 1980's thriller detailing the tracing of a cracker from
  947. Berkeley across the USA and over the Atlantic to Germany.  An excellent
  948. view from all points: a good read, informative about security, funny,
  949. and a good illustration of the cracker psyche.  Contains an excellent
  950. recipie for chocolate chip cookies.
  951.  
  952. A videotape of the "NOVA" (PBS's Science Program on TV) episode that
  953. explained/reenacted this story is available from PBS Home Video.  They
  954. have a toll-free 800 number within North America.
  955.  
  956. I believe that this program was aired on the BBC's "HORIZON" program,
  957. and thus will be available from BBC Enterprises, but I haven't checked
  958. this out yet - AEM
  959.  
  960. [Raymond] (Ed.)
  961. The New Hackers Dictionary/Online Jargon File
  962.  
  963. A mish-mash of history and dictionary definitions which explains why it
  964. is so wonderful to be a hacker, and why those crackers who aren't
  965. hackers want to be called "hackers".  The Jargon File version is
  966. available online - check an archie database for retails.  Latest
  967. revision: 2.9.12.
  968.  
  969. [Gasser]
  970. Building a Secure Computer System.
  971.  
  972. By Morrie Gasser, and van Nostrand Reinhold; explains what is required
  973. to build a secure computer system.
  974.  
  975. [Rainbow Series] (Especially the "Orange Book")
  976.  
  977. >From: epstein@trwacs.fp.trw.com (Jeremy Epstein)
  978. >The "Rainbow Series" consists of about 25 volumes.  Some of the
  979. >more interesting ones are:
  980. >
  981. >    The "Orange Book", or Trusted Computer Systems Evaluation
  982. >        Criteria, which describes functional and assurance
  983. >        requirements for computer systems
  984. >
  985. >    Trusted Database Interpretation, which talks both about
  986. >        trusted databases and building systems out of trusted
  987. >        components
  988. >
  989. >    Trusted Network Interpretation, which (obviously) talks
  990. >        about networked systems
  991. >
  992. >A (possibly) complete list is:
  993. >    -- Department of Defense Trusted Computer System Evaluation Criteria
  994. >       (TCSEC), aka the "Orange Book"
  995. >    -- Computer Security Subsystem Interpretation of the TCSEC
  996. >    -- Trusted Data Base Management System Interpretation of the TCSEC
  997. >    -- Trusted Network Interpretation of the TCSEC
  998. >    -- Trusted Network Interpretation Environments Guideline -- Guidance
  999. >       for Applying the Trusted Network Interpretation
  1000. >    -- Trusted Unix Working Group (TRUSIX) Rationale for Selecting
  1001. >       Access Control List Features for the Unix System
  1002. >    -- Trusted Product Evaulations -- A Guide for Vendors
  1003. >    -- Computer Security Requirements -- Guidance for Applying the DoD
  1004. >       TCSEC in Specific Environments
  1005. >    -- Technical Rationale Behind CSC-STD-003-85: Computer Security
  1006. >       Requirements
  1007. >    -- Trusted Product Evaluation Questionnaire
  1008. >    -- Rating Maintenance Phase -- Program Document
  1009. >    -- Guidelines for Formal Verification Systems
  1010. >    -- A Guide to Understanding Audit in Trusted Systems
  1011. >    -- A Guide to Understanding Trusted Facility Management
  1012. >    -- A Guide to Understanding Discretionary Access Control in Trusted
  1013. >       Systems
  1014. >    -- A Guide to Understanding Configuration Management in Trusted Systems
  1015. >    -- A Guide to Understanding Design Documentation in Trusted Systems
  1016. >    -- A Guide to Understanding Trusted Distribution in Trusted Systems
  1017. >    -- A Guide to Understanding Data Remanence in Automated Information
  1018. >       Systems
  1019. >    -- Department of Defense Password Management Guideline
  1020. >    -- Glossary of Computer Security Terms
  1021. >    -- Integrity in Automated Information Systems
  1022. >
  1023. >You can get your own copy (free) of any or all of the books by
  1024. >writing or calling:
  1025. >
  1026. >    INFOSEC Awareness Office
  1027. >    National Computer Security Centre
  1028. >    9800 Savage Road
  1029. >    Fort George G. Meade, MD  20755-6000
  1030. >    Tel +1 301 766-8729
  1031. >
  1032. >If you ask to be put on the mailing list, you'll get a copy of each new
  1033. >book as it comes out (typically a couple a year).
  1034.  
  1035. >From: kleine@fzi.de (Karl Kleine)
  1036. >I was told that this offer is only valid for US citizens ("We only send
  1037. >this stuff to a US postal address").  Non-US people have to PAY to get
  1038. >hold of these documents.  They can be ordered from NTIS, the National
  1039. >Technical Information Service:
  1040. >    NTIS,
  1041. >    5285 Port Royal Rd,
  1042. >    Springfield VA 22151,
  1043. >    USA
  1044. >    order dept phone: +1-703-487-4650, fax +1-703-321-8547
  1045.  
  1046. >From: Ulf Kieber <kieber@de.tu-dresden.inf.freia>
  1047. >just today I got my set of the Rainbow Series.
  1048. >
  1049. >There are three new books:
  1050. > -- A Guide to Understanding Trusted Recovery in Trusted Systems
  1051. > -- A Guide to Understanding Identification and Authentication in Trusted
  1052. >    Systems
  1053. > -- A Guide to Writing the Security Features User's Guide for Trusted Systems
  1054. >
  1055. >They also shipped
  1056. > -- Advisory Memorandum on Office Automation Security Guideline
  1057. >issued by NTISS.  Most of the books (except three or four) can also be
  1058. >purchased from
  1059. >
  1060. >    U.S. Government Printing Office
  1061. >    Superintendent of Documents
  1062. >    Washington, DC 20402        phone: (202) 783-3238
  1063. >
  1064. >>-- Integrity in Automated Information Systems
  1065. >THIS book was NOT shipped to me--I'm not sure if it is still in
  1066. >the distribution.
  1067.  
  1068. >From: epstein@trwacs.fp.trw.com (Jeremy Epstein)
  1069. >...
  1070. >The ITSEC (Information Technology Security Evaluation Criteria) is a
  1071. >harmonized document developed by the British, German, French, and
  1072. >Netherlands governments.  It separates functional and assurance
  1073. >requirements, and has many other differences from the TCSEC.
  1074. >
  1075. >You can get your copy (again, free/gratis) by writing:
  1076. >
  1077. >    Commission of the European Communities
  1078. >    Directorate XIII/F
  1079. >    SOG-IS Secretariat
  1080. >    Rue de la Loi 200
  1081. >    B-1049 BRUSSELS
  1082. >    Belgium
  1083.  
  1084. Also note that NCSC periodically publish an "Evaluated Products List"
  1085. which is the definitive statement of which products have been approved
  1086. at what TCSEC level under which TCSEC interpretations.  This is useful
  1087. for separating the output of marketdroids from the truth.
  1088.  
  1089. Papers:
  1090.  
  1091. [Morris & Thompson]
  1092. Password Security, A Case History
  1093.  
  1094. A wonderful paper, first published in CACM in 1974, which is now often
  1095. to found in the Unix Programmer Docs supplied with many systems.
  1096.  
  1097. [Curry]
  1098. Improving the Security of your Unix System.
  1099.  
  1100. A marvellous paper detailing the basic security considerations every
  1101. Unix systems manager should know.  Available as "security-doc.tar.Z"
  1102. >From FTP sites (check an Archie database for your nearest site.)
  1103.  
  1104. [Klein]
  1105. Foiling the Cracker: A Survey of, and Improvements to, Password Security.
  1106.  
  1107. A thorough and reasoned analysis of password cracking trends, and the
  1108. reasoning behind techniques of password cracking.  Your nearest copy
  1109. should be easily found via Archie, searching for the keyword "Foiling".
  1110.  
  1111. [Cheswick]
  1112. The Design of a Secure Internet Gateway.
  1113.  
  1114. Great stuff.  It's in research.att.com:/dist/internet_security/gateway.ps
  1115.  
  1116. [Cheswick]
  1117. An Evening With Berferd: in which a Cracker is Lured, Endured and Studied.
  1118.  
  1119. Funny and very readable, somewhat in the style of [Stoll] but more
  1120. condensed.  research.att.com:/dist/internet_security/berferd.ps
  1121.  
  1122. [Bellovin89]
  1123. Security Problems in the TCP/TP Protocol Suite.
  1124.  
  1125. A description of security problems in many of the protocols widely used
  1126. in the Internet.  Not all of the discussed protocols are official
  1127. Internet Protocols (i.e.  blessed by the IAB), but all are widely used.
  1128. The paper originally appeared in ACM Computer Communications Review,
  1129. Vol 19, No 2, April 1989.  research.att.com:/dist/ipext.ps.Z
  1130.  
  1131. [Bellovin91]
  1132. Limitations of the Kerberos Authentication System
  1133.  
  1134. A discussion of the limitations and weaknesses of the Kerberos
  1135. Authentication System.  Specific problems and solutions are presented.
  1136. Very worthwhile reading.  Available on research.att.com via anonymous
  1137. ftp, originally appeared in ACM Computer Communications Review but the
  1138. revised version (identical to the online version, I think) appeared in
  1139. the Winter 1991 USENIX Conference Proceedings.
  1140.  
  1141. [Muffett]
  1142. Crack documentation.
  1143.  
  1144. The information which accompanies Crack contains a whimsical explanation
  1145. of password cracking techniques and the optimisation thereof, as well as
  1146. an incredibly long and silly diatribe on how to not choose a crackable
  1147. password.  A good read for anyone who needs convincing that password
  1148. cracking is _really easy_.
  1149.  
  1150. [Farmer]
  1151. COPS
  1152.  
  1153. Read the documentation provided with COPS.  Lots of hints and
  1154. philosophy.  The where, why and how behind the piece of security
  1155. software that started it all.
  1156.  
  1157. [CERT]
  1158. maillists/advisories/clippings
  1159.  
  1160. CERT maintains archives of useful bits of information that it gets from
  1161. USENET and other sources.  Also archives of all the security
  1162. "advisories" that it has posted (ie: little messages warning people that
  1163. there is a hole in their operating system, and where to get a fix)
  1164.  
  1165. [OpenSystemsSecurity]
  1166.  
  1167. A notorious (but apparently quite good) document, which has been dogged
  1168. by being in a weird postscript format.
  1169.  
  1170. >From: amesml@monu1.cc.monash.edu.au (Mark L. Ames)
  1171.  
  1172. >I've received many replies to my posting about Arlo Karila's paper,
  1173. >including the news (that I and many others have missed) that a
  1174. >manageable postscript file and text file are available via anonymous ftp
  1175. >from ajk.tele.fi (131.177.5.20) in the directory PublicDocuments.
  1176.  
  1177. These are all available for FTP browsing from "cert.sei.cmu.edu".
  1178.  
  1179. [RFC-1244]
  1180. Site Security Handbook
  1181.  
  1182. RFC-1244 : JP Holbrook & JK Reynolds (Eds.) "The Site Security Handbook"
  1183. covering incident handling and prevention.  July 1991; 101 pages
  1184. (Format: TXT=259129 bytes), also called "FYI 8"
  1185.  
  1186. [USENET]
  1187. comp.virus: for discussions of virii and other nasties, with a PC bent.
  1188. comp.unix.admin: for general administration issues
  1189. comp.unix.<platform>: for the hardware/software that YOU use.
  1190. comp.protocols.tcp-ip: good for problems with NFS, etc.
  1191.  
  1192.  
  1193. Q.20 How silly can people get?
  1194.  
  1195. This section (which I hope to expand) is a forum for learning by
  1196. example; if people have a chance to read about real life (preferably
  1197. silly) security incidents, it will hopefully instill in readers some of
  1198. the zen of computer security without the pain of experiencing it.
  1199.  
  1200. If you have an experience that you wish to share, please send it to the
  1201. editors.  It'll boost your karma no end.
  1202.  
  1203. ---------------------------------------------------------------------------
  1204. aem@aber.ac.uk: The best story I have is of a student friend of mine
  1205. (call him Bob) who spent his industrial year at a major computer
  1206. manufacturing company.  In his holidays, Bob would come back to college
  1207. and play AberMUD on my system.
  1208.  
  1209. Part of Bob's job at the company involved systems management, and the
  1210. company was very hot on security, so all the passwords were random
  1211. strings of letters, with no sensible order.  It was imperative that the
  1212. passwords were secure (this involved writing the random passwords down
  1213. and locking them in big, heavy duty safes).
  1214.  
  1215. One day, on a whim, I fed the MUD persona file passwords into Crack as a
  1216. dictionary (the passwords were stored plaintext) and then ran Crack on
  1217. our systems password file.  A few student accounts came up, but nothing
  1218. special.  I told the students concerned to change their passwords - that
  1219. was the end of it.
  1220.  
  1221. Being the lazy guy I am, I forgot to remove the passwords from the Crack
  1222. dictionary, and when I posted the next version to USENET, the words went
  1223. too.  It went to the comp.sources.misc moderator, came back over USENET,
  1224. and eventually wound up at Bob's company.  Round trip: ~10,000 miles.
  1225.  
  1226. Being a cool kinda student sysadmin dude, Bob ran the new version of
  1227. Crack when it arrived.  When it immediately churned out the root
  1228. password on his machine, he damn near fainted...
  1229.  
  1230. The moral of this story is: never use the same password in two different
  1231. places, and especially on untrusted systems (like MUDs).
  1232. --
  1233. Alec Muffett (alec.muffett@sun.co.uk) Sun Microsystems IR, Bagshot, Surrey, UK
  1234.                          #include <stddisclaimer.h>
  1235.  
  1236.